satellaviewfandomcom-20200214-history
Satellaview ROM header
The internal header of a Satellaview ROM is the portion of the ROM's code used by coders to hold identifying information (such as the maker, title, and date), to impose play-through limits on gamers (such as start-up limits and deletion-imposed limits), to describe game specifics (such as size, speed, and pointer values), and to safeguard the integrity of the ROM (as by checksum counts). The fact that many emulators and ips patchers require the header to be removed in order to function properly demonstrates that header information is not necessary for the functionality of the Satellaview program, however the automatic removal of the header results in the loss of historical information that may never be recovered. Information such as the date and the version number are of particular interest to Satellaview researchers and preservationists as these data indicate whether the ROM is a new ROM or a true redump as well as allowing for the proper naming of the restored game. Although some Satellaview games were re-broadcast on different dates with no alterations apart from the date in the header, other games were re-broadcast with subtly remixed content in order to provide a new experience even for players that had played through a previous run. The prototypical example of such an alteration is the positioning of the Mole character in BS Zelda no Densetsu: Inishie no Sekiban. By examining header information such as the date and version number, researchers are able to know for sure that all broadcasts of a game have been accounted for. This allows for the preservation (or at least the documentation) of even remix versions of Satellaview games. Technical information The header of a Satellaview ROM resides at one of two addresses when examining an unaltered ROM with a hex editorHex editors are programs that allow users to access the raw binary data (1s and 0s) making up all computer programs. This kind of editor allocates hexadecimal addresses to strings of binary in order to enable simplified navigation of the program and to help see the structure of the low-level programming language such files are written in - assembly language (or ASM for short). depending on the ROM's "map mode." All known Satellaview ROMs can be described as being mapped in either "HiROM" or "LoROM,"The terms "HiROM" and "LoROM" are actually ways to describe how the program responds to the addresses found on the SFC's Address Bus A - the 24-bit bus associated with WRAM. If the ROM is mapped as "LoROM" then the ROM data only successively associates with the first half of each data bank on the SFC. This allows easy access to the WRAM which maps from the second half of each data bank, however it limits the size of each data bank to 32K. If the program designers had instead mapped the ROM as "HiROM" then each data bank has a maximum size of 64K, however this means that the location of code writing to the SRAM must be shifted. The decision to use "LoROM" or "HiROM" mapping is up to the program designers, and the internal heuristics of most modern emulators allow for a high degree of map mode detection. and the header begins at the 32,688th binary digit (hex address 0x7FB0) for LoROM files and at the 65,456th binary digit (hex address 0xFFB0) for HiROM files.Complicating matters somewhat, many Satellaview ROMs extracted from 8M memory packs and existing online also contain "ROM Copier headers" that were added to the ROM as part of the copying process. ROM Copier headers were not originally part of the broadcast ROM, however they have little or no effect on the ROM apart from introducing a 200-byte offset to all internal addresses. For a ROM-Copier-headered LoROM file, the original internal header can be located at hex address 0x81B0 for a LoROM file and at hex address 0x101B0 for a HiROM file. Details Title Titles are rendered in SJIS using a combination of single-byte English characters, half-width katakana, and diacritics (all from JIS X 0201), and 2-byte kanji (from JIS X 0208 (JIS基本漢字)). Below we examine three examples: In the above 3 examples, it is clear that different naming conventions are used even for different games within the same series. Example 1 illustrates the importance of internal header names as a means by which to determine episode number as the title ends with "第3話" (Dai 3 Wa). This example also demonstrates variation that is introduced by the redundancy built into SJIS as the character "3" is encoded using the lengthier 8252_{hex} instead of 33_{hex} . Example 2 illustrates the use of JIS-X-0201-form combined characters as the half-width katakana, "ｾ", and the "ﾞ" diacritic together become "ｾﾞ" (and likewise "ﾀ" and "ﾞ" become "ﾀﾞ"). Taken together with example 1, this example also demonstrates variability of naming convention as example 1 terminated the title with a string of blank spaces whereas example 2 simply failed to use this part of the region reserved for title. In addition, example 1 used English characters to spell out "ZELDA" whereas example 2 used katakana to spell out "ｾﾞﾙﾀﾞ". Example 3, then, illustrates yet a third naming possibility as the full internal title "神々のﾄﾗｲﾌｫｰｽ " (Kamigami no Triforce) is in fact nothing but the actual game's subtitle. Block Allocation The portion of the header describing which blocks are allocated for the software in question, i.e. where the data is actually stored on the data pack. The data packs can hold multiple ROMs and up to 32 Mbits can be allocated for them, although only 8 Mbit FLASH cartridges were manufactured. In general, retail re-releases and demos intended to be given a retail release were described as "FFFF". Satellaview-only games are described as "00-FF", and add-on maskrom data packs were described as "0000". Examples are given below: One bit corresponds to one megabit block on the Data Pack, with the MSB being the last “page” ($C80000-$CFFFFF) and the LSB being the first ($C00000-$C7FFFF). No known Satellaview ROMs that are marked $00 will detect on the Satellaview itself. Limited starts Many Satellaview downloads were designed to expire after a certain number of play-throughs. This primitive form of digital rights management (DRM) operates by employing a simple boot-up countdown that goes into effect for all programs with certain "Limited start" values. With a maximum of 5 play-throughs, each boot-limited game is altered by the BS-X BIOS in such a way as to decrease the "boots left"-count every time it is booted. When a Satellaview download is booted from the BS-X BIOS, the BIOS makes a quick check of the "Limited starts" section (0xxFD4-0xxFD5) of the ROM header. If the value at this address represents "0 boots left" (i.e. 80_{hex} ), then the game is considered "locked" (or "expired"). Although the game can now no longer be booted in this state, however, the only difference between the "1 boot left" state and the "0 boot left" state is 1 bit. This is another way of saying that the game data has not been wiped clean, but that it has merely been marked as unplayable. During the period of Satellaview broadcasts between 1995 and 2000 this meant that the player would have had to re-download the game (if it was available) in order to play again with a full play-count. With modern emulation it means that the player will have to use an emulator that ignores boot limits or simply edit this portion of the ROM with a hex editor to restore functionality.KiddoCabbusses. Explaining BS-X “lockout” – why your Zelda pack won’t play anymore. (sorry dude.). Satellaview. 29 March 2010. For Satellaview ROMs that are distributed as originally dumped data and that are therefore still "locked," researchers and recreationists have taken to marking the file name with the symbol "(L)."KiddoCabbusses. The Perils of 8M Pack Purchasing; Kaizou Choujin Shubibinman Zero.. Satellablog. 2 January 2011. Boot limits didn't apply to SoundLink titles since they were never designed to boot and thus were "locked" from the outset, however boot limits were very common with most non-SoundLink titles. The two major exceptions to this general rule were Nintendo first party downloads (such as Special Tee Shot and the Kirby no Omocha Hako line) and Squaresoft's games. These games had a value of 00_{hex} for the "Limited starts" field and were thus granted unlimited boots. These DRM-free gifts are valued today by collectors as the only way to play fully hardware Satellaview titles subsequent to the demise of the system and their lack of an expiry condition means that they have thankfully been preserved in large part for the enjoyment of subsequent generations of players. To describe exactly how the boot-up countdown functioned, it is important to note that of the 8 bits present in the "Limited starts" field, only the upper 6 were used to convey limit information; the last 2 bits were always 0_{bin} . If the first upper bit in the "limited starts" field were filled with a 1_{bin} (i.e. 1xxxxxxx_{bin} ), then the game would be regarded as a boot-limited game. Assuming that upper bits 2 through 6 weren't all filled with 0_{bin} (i.e. 100000xx_{bin} ), the BIOS would convert the leading 1_{bin} (of upper bits 2 through 6) to 0_{bin} . Thus, x11111xx_{bin} would become x01111xx_{bin} after the first boot, then x00111xx_{bin} after the second boot, x00011xx_{bin} after the third, x00001xx_{bin} after the fourth, and finally x00000xx_{bin} after the fifth boot. Such a game would have expired at this point, would have failed the initial boot limit check, and would thus be locked. The following table given the known limited boot header values: Note: It has been claimed that the Ultra 16, a hardware emulator shell similar to the Super UFO, can play locked ROMsKiddoCabbusses. Explaining BS-X “lockout” – why your Zelda pack won’t play anymore. (sorry dude.). Satellaview. 29 March 2010. and locked memory packs. According to d4s, even deleted games (see below) can be played using an Ultra 16 unit.KiddoCabbusses. Just how difficult is getting new stuff? A sorta-personal story.. Satellablog. 1 June 2010. Non-boot limits For a number of games, research appears to suggest that alternative means were used to preserve the digital rights to the media for the game creators. Rather than simply employing a boot-up countdown as described above, some other games appear to have semi-scrambled information contained within themselves. For Satellaview ROMs that had blank checkbit fields, the ROM would not boot properly. Similarly, for ROMs in which the Maker values were set at anything other than 33_{hex} , the ROM would also fail to boot properly. Explanations for these seemingly corrupt ROMs include alternate methods of file deletion and corrupted dump data (missing data, corrupt image, or incorrect mapping) Date The date portion of the header comprises 2 bytes and is split between month (the upper 4 bits of the first byte, 0xxFD6_{hex} ) and day (the upper 5 bits of the second byte, 0xxFD7_{hex} ). All other digits in the date portion (i.e. the lower 4 bits of the first byte and the lower 3 bits of the second byte) are filled with 0_{bin} . Two examples of header dates are shown below: Dates like those given in the examples above are extremely helpful for Satellaview researchers and preservationists to give a sense of whether or not ROM material is new (previously undumped material) or redump material. Although some data broadcasts were identical save for their header dates, such information is still of great importance to researchers as unique dates represent possibilities of new material within a finite set of data broadcasts. Examples such as that of the positioning of the Mole character in BS Zelda no Densetsu: Inishie no Sekiban discussed above demonstrate that remixed versions of the same game did exist and are of great interest to collectors and Satellaview enthusiasts. For this reason, Satellaview researchers have taken to marking the ROM file name with the header date.KiddoCabbusses. Redumps. Because sometimes identical ROMs happen, except for the times they aren’t -that- identical.. Satellaview. 9 April 2010. Below are two further examples, however, that demonstrate that header date information is not always a perfect means by which to identify discrete ROM dumps: As the two examples above show, ROM header information may occasionally be corrupt. In example 3, a possible date of August 20 can be determined from the header, however the issue is clouded by the unexplained presence of trailing 1_{bin} characters (lower 2 bits of the second byte - 0xFFD7). In example 4, however, the date information appears to be scrambled beyond usability. Problems like this may be due to improper dumping of the original ROM, subsequent corruption of the header data by ROM hackers or due to data decay, or possibly even attempts by the original creators to scramble the information for DRM reasons. ROM Speed & Map mode The portion of the header describing the ROM Speed and map mode comprises only a single byte with the upper 4 bits representing the ROM speed and the lower 4 bits representing the map mode. For the ROM Speed, values of 0000_{bin} , 0001_{bin} , and 0010_{bin} describe SlowROM (i.e. the ROM Speed is 200 nano-seconds). For values of 0011_{bin} and greater, FastROM (i.e. a ROM Speed of 120 nano-seconds) is described. Map mode descriptions are even simpler, with only two allowed values: 0000_{bin} represents LoROM and 0001_{bin} represents HiROM. Two examples follow: Note that the two characteristics of ROM Speed and Map mode are not tied together as the above examples might indicate, and the two values do not have direct bearing on each other. Thus, a Hex value of 30 would indicate a FastROM speed for a LoROM map mode. Type The portion of the header describing the ROM Type comprises only the upper 4 bits of a single byte - 0xxFD9. The lower 4 bits are all 0_{bin} characters. There are 4 normal types allowed in ROM headers and a 5th default error type for all other values. The following chart describes the 5 values: Licensee / Maker The portion of the header describing the Licensee/Maker comprises a single byte - 0xxFDA. There are 2 normal types allowed in ROM headers and only one that allows the ROM to be booted. For ROMs with a Licensee/Maker value of 33_{hex} , the ROM will boot properly and be viewable. For ROMs with a Licensee/Maker value of FF_{hex} , the ROM will not be bootable. There has been some speculation that this may have been an attempt by the original creators to disable the ROM for DRM reasons. Version Number The Version Number is an extension the actual format of which is 1 + ord(val($ffdb))/10. Checkbits The portion of the header comprising the checkbit data can be found in the 4 bytes between hex addresses 0xxFDC and 0xxFDF. The first 2 bytes (0xxFDC and 0xxFDD) represent the ROM's Checksum and the second 2 bytes (0xxFDE and 0xxFDF) represent the Inverse Checksum. When added together, these two figures should total FFFF_{hex} for a proper ROM. If the Checksum and Inverse Checksum are blank, then the ROM will not boot. This has been observed in some ROMs in the past and there has been speculation that this may represent an attempt by the original creators to disable the ROM for DRM reasons. Additionally, when calculating the Checksum (0xxFDC and 0xxFDD) for each title saved on the data pack, the Block Allocation bits (located at 0xxFD0) should be used to determine which blocks the checksum will be calculated from. Pointers The portion of the header comprising the pointers can be found in the 28 bytes at the end of the header between hex addresses 0xxFE4 and 0xxFFF. The main pointer that points to the Program Start is usually located at 0xxFFC_{hex} , and pointers are usually 16-bit pointers. Notes References External links *Internal ROM Header - An SMWiki article about the Internal ROM Header present in Mario games. *BS-X Satellaview Header - An article about Satellaview ROM headers hosted at superfamicom.org's wiki. Category:Broadcast data